Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-039

Text File | 1995-12-31 | 56.2 KB | 1,682 lines | [TEXT/R*ch]

Received-Date: Sun, 26 Jun 1994 23:31:02 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-039
To: [e-mail]
Date: Sun, 26 Jun 1994 23:30:56 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 42

C.S.M.P. Digest             Sun, 26 Jun 94       Volume 3 : Issue 39

Today's Topics:

        API-headers for Control Strip Modules?
        Apple Event Question
        Are NewPtr() and malloc() different? (source included)
        Closing Down the FINDER
        Fat-stripping
        Finder Comments and Finder Info Updating
        MacTech's ftp site now available!
        QuickDraw GX Display Devices
        SEMI-SUMMARY: Reading JPEGs (with code)
        VBL interrupt & Stack Sniffer
        Writing dcmd with Think C (Q)



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From Gordie Freedman <[e-mail]>
Subject: API-headers for Control Strip Modules?
Date: 8 Jun 1994 07:17:19 GMT
Organization: Kaleida Labs, Inc.

Anybody know where the API is documented to write control strip modules?
I also wasn't sure if there were any header files you used with this
stuff, or if you had to roll your own. Thanks in advance,

Gordie Freedman
--

[e-mail] - Kaleida Labs, Inc. - Mountain View, CA

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Wed, 08 Jun 1994 21:42:50 -0700
Organization: Infinity Systems

In article <2t3r9v$[e-mail]>, Gordie Freedman
<[e-mail]> wrote:

> Anybody know where the API is documented to write control strip modules?
> I also wasn't sure if there were any header files you used with this
> stuff, or if you had to roll your own. Thanks in advance,

They're in the PowerBook 500-series technical notes, which were included on
the June Developer CD.  As far as a header file goes, I didn't see anything
included.

_troy
//////// //////___Troy [e-mail]__ //
  //    //       Infinity Systems ; Redmond, Washington                //
 //    //  //  "Insert witty quote here."                             //
//    //////________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Sat, 11 Jun 1994 09:12:12 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Gordie Freedman ([e-mail]) wrote:
> Anybody know where the API is documented to write control strip modules?
> I also wasn't sure if there were any header files you used with this
> stuff, or if you had to roll your own. Thanks in advance,

For that matter, can you get the software any way without buying a 500?

Not that I don't want a 500...

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Sat, 11 Jun 1994 22:46:33 -0700
Organization: Infinity Systems

In article <[e-mail]>, [e-mail] (Jon Pugh)
wrote:

> Gordie Freedman ([e-mail]) wrote:
> > Anybody know where the API is documented to write control strip modules?
> > I also wasn't sure if there were any header files you used with this
> > stuff, or if you had to roll your own. Thanks in advance,
>
> For that matter, can you get the software any way without buying a 500?
>
> Not that I don't want a 500...

I tried a copy of Control Strip, grabbed off the hard drive of a 500, and
tried it on a desktop Mac, and it wouldn't function, but it worked fine on
a PowerBook 140.

I certainly hope that they allow it to work on desktop Macs as well soon.
I'd like to use it for a few things myself (like volume and monitor
depth-switching), and its modular architecture makes it easy for third
parties to write modules that would be useful for users of desktop
machines.

_troy
//////// //////___Troy [e-mail]__ //
  //    //       Infinity Systems ; Redmond, Washington                //
 //    //  //  "Insert witty quote here."                             //
//    //////________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 12 Jun 1994 14:54:34 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail] (Jon Pugh) wrote:

>For that matter, can you get the software any way without buying a 500?

Yes.  Get a 280 (:
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 12 Jun 1994 23:08:17 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>,
[e-mail] (Troy Gaul) wrote:

>I tried a copy of Control Strip, grabbed off the hard drive of a 500, and
>tried it on a desktop Mac, and it wouldn't function, but it worked fine on
>a PowerBook 140.

The guys at the WWDC session said they would consider moving it to the
desktop Macs depending on how it was received on the PowerBooks.
Personally I think it's a TOE (Thing Of Evil (tm)).  That won't stop me
using it of course (:
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  Now if only the 280C I have on order would arrive ):

---------------------------

>From [e-mail] (Jonathon M. Lipsky)
Subject: Apple Event Question
Date: 2 Jun 1994 20:01:16 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


I would like to know if anyone has created their own
AppleEvents to pass data between two programs.  What
I would like to do is impliment an event similar to
an OpenDocument, but I would like to pass a string
that the recieving program that would give it the
needed information.  All of my attempts at implimenting
this have not succeeded, so any examples would be
greatly appreciated.

Jon Lipsky ([e-mail])

+++++++++++++++++++++++++++

>From Here@There (Someone)
Date: 10 Jun 1994 17:29:50 GMT
Organization: Large Fuzzy Room

There's lots of samples around, adapting a 'real' AppleEvent to your
private needs will be easiest.  Here's one way you might want to implement
the send and recieve functions (VERY simple here)

// a coupla defines
#define kMyPrivateEventClass 'MYEV'
#define kOpenFileStringEvent 'OPFS'
#define typeMyPString 'MPST'
// Get the address (through PPCBrowser or elsewhere) and the
// file string and pass them in
OSErr SendFileNameString(ConstStr255 theFullPath,AEDesc * theAddress)
{
AppleEvent theEvent;
OSErr theError = noErr;
// create the event
theError = AECreateAppleEvent(kMyPrivateEventClass,kOpenFileStringEvent,
theAddress,kAutoGenerateReturnID,kAnyTransactionID,&theEvent);
// if no error, add our string
if(theError == noErr)
theError=
AEPutParamPtr(&theEvent,keyDirectObject,typeMyPString,(Ptr)&theFullPath[1],theFullPath[0]);
// send the event
if(theError == noErr)
theError =
AESend(&theEvent,nil,kAENoReply,kAENormalPriority,kAEDefaultTimeout,(IdleProcPtr)
nil,nil);

return( theError );
}


// and on the recieving end, get the thing out

pascal OSErr HandleMyOpenFileStr(AppleEvent *messagein, AppleEvent *reply,
long refIn)
{OSErr theError = noErr;
Str255 fileString;
DescType returnedType;
Size returnedSize;
// get the string from the event
theError = AEGetParamPtr(messagein,   // from this event
                           keyDirectObject,    // get the direct object
                           typeMyPString,       // as a pstring
                           &returnedType,
                           (Ptr)&fileString[1],  // put it here
                           254,      // max size
                           &returnedSize);
if(theError == noErr){
fileString[0] = returnedSize;
theError  = FSOpen(fileString, nil,&fileRefNum);
// fileRefNum is somewhere, whereever you need it
}
return ( theError);
}

---------------------------

>From [e-mail] (Chris Reid)
Subject: Are NewPtr() and malloc() different? (source included)
Date: Mon, 06 Jun 1994 12:15:52 +0000
Organization: University of Strathclyde

Hi everybody,

I have written some code that implements Radix Sort (it sorts
an array of longs in linear time). It seems to work well enough,
but one thing is really strange: when I replace the NewPtr()
calls with calls to malloc(), the corresponding free() doesn't seem
to work. Here's roughly what happens:


// RadixSort implemented using NewPtr() and DisposPtr()

mem = FreeMem();    // We've got amount 'mem' bytes in the heap
RadixSort(someArray, numItems);    // Do the sorting
waste = mem - FreeMem();    // Is there a memory leak?

waste is always zero (just as it should be), BUT:

// RadixSort implemented using malloc() and free()

mem = FreeMem();    // We've got amount 'mem' bytes in the heap
RadixSort(someArray, numItems);    // Do the sorting
waste = mem - FreeMem();    // Is there a memory leak?

waste is non-zero, a very disturbing fact. But it gets even better,
because on consecutive calls, waste IS zero. It looks as if
malloc() remebers what it's done before. By the way, I need to
use malloc() because the code has to be (sort of) platform independent.

The source is attached (hence the cross-posting to alt.sources.mac).
It works, so feel free to use it. Something must be going wrong somewhere,
I can't see it, can anybody else? I'm using THINK C 6.0.1 with Objects.

Thanks in advance folks!


Chris

PS: a description of Radix Sort can be found in almost any books on
algorithms

/********** Radix Sort Source *************************/

#define MAC

#ifdef MAC
#define BYTE0 3
#define BYTE1 2
#define BYTE2 1
#define BYTE3 0
#endif

// for PC's or any other Big Endian...
#ifdef PC
#define BYTE0 0
#define BYTE1 1
#define BYTE2 2
#define BYTE3 3
#endif

#define kNumElements    500        // allocate space for 500 longs at a time
#define kNumPasses        4                    // 32 bit longs - split into 4 * 8 bits
#define kNumBuckets        256  // require 256 buckets
#define kMaxBuffer        100            // sort at most 100 * 500 = 50000 items

typedef long    Buffer[kNumElements];    // we don't want to hammer the memory
manager
typedef Buffer    *BufferPtr;                                    // so we allocate space for 500 longs

typedef struct
        {
            BufferPtr        theBuffers[kMaxBuffer]; // hold the items as they are added
            long            numItems;                                                                            // how many (filled) buffers have we
got?
            long            current;                                                                                // where does next item go?
        } Bucket, *BucketPtr;


static BucketPtr theBuckets[kNumBuckets];    // our buckets...


// allocate space for the buckets and init
void SetupBuckets(void)
{
    long    i, k;

    for (i = 0; i < kNumBuckets; i++)
    {
        theBuckets[i] = (BucketPtr) NewPtr(sizeof(Bucket));

        for (k = 0; k < kMaxBuffer; k++) theBuckets[i]->theBuffers[k] = NULL;
        theBuckets[i]->numItems = 0;
        theBuckets[i]->current = 0;
    }
}

// We're done, release memory
void ClearBuckets(void)
{
    long    i, k;

    for (i = 0; i < kNumBuckets; i++)
    {
        for (k = 0; theBuckets[i]->theBuffers[k] != NULL; k++)
        {
            DisposPtr((Ptr) theBuckets[i]->theBuffers[k]);
        }
        DisposPtr((Ptr) theBuckets[i]);
    }
}

// Stuff what we've put into the buffers back into the array and release
mem.
void CopyBuckets(long theArray[])
{
    register long    i, j, k, l, count;

    count = 0;
    for (i = 0; i < kNumBuckets; i++)
    {
        for (j = 0; j <= theBuckets[i]->numItems; j++) // number of filled
buffers
        {
            if (j < theBuckets[i]->numItems) l = kNumElements; //full buffer
            else l = theBuckets[i]->current;                                                                            //partially full

            for (k = 0; k < l; k++)
            {
                theArray[count] = (*theBuckets[i]->theBuffers[j])[k];
                count++;
            }
         if (theBuckets[i]->theBuffers[j])
            {
                free((void *) theBuckets[i]->theBuffers[j]);
                theBuckets[i]->theBuffers[j] = NULL;
            }
        }
        theBuckets[i]->numItems = 0;
        theBuckets[i]->current = 0;
    }
}


void RadixSort(long theArray[], long numItems)
{
    register long    i, k;
    register unsigned char    c;
    short Offset[kNumPasses] = {BYTE0,BYTE1,BYTE2,BYTE3};
     unsigned char *p;

    long    mem, waste;

    mem = FreeMem();

    SetupBuckets();

    for (i = 0; i < kNumPasses; i++)
    {
        for (k = 0; k < numItems; k++)
        {

             p = (unsigned char *) &theArray[k] + Offset[i];
             c = *p;
            if (!theBuckets[c]->theBuffers[theBuckets[c]->numItems])
            {
                theBuckets[c]->theBuffers[theBuckets[c]->numItems] = (BufferPtr)
malloc(sizeof(Buffer));
                theBuckets[c]->current = 0;
            }

            (*theBuckets[c]->theBuffers[theBuckets[c]->numItems])[theBuckets[c]->current]
= theArray[k];

            theBuckets[c]->current++;
            if (theBuckets[c]->current >= kNumElements)
            {
                theBuckets[c]->numItems++;
                theBuckets[c]->current = 0;
            }
        }
        CopyBuckets(theArray);
    }
    ClearBuckets();
    waste = mem - FreeMem();
}



+-----------------------------------------------------------------+
|Chris Reid                            e-mail: [e-mail] |
|Dept. Computer Science, Strathclyde University, Glasgow, Scotland|
+-----------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Mon, 6 Jun 1994 14:42:31 GMT
Organization: PRZ TU-Berlin

[e-mail] (Chris Reid) writes:
>
>Hi everybody,
>
>I have written some code that implements Radix Sort (it sorts
>an array of longs in linear time). It seems to work well enough,
>but one thing is really strange: when I replace the NewPtr()
>calls with calls to malloc(), the corresponding free() doesn't seem
>to work. Here's roughly what happens:
>
[stuff deleted]

Well, as I remember, malloc() calls _NewPtr, but free() (at least
in the THINK C implementation) does not (necessarily) call _DisposPtr.
The malloc/free implementation does some of its own store management.
So, what you're seeing is not (ahem, necessarily) a memory leak.
Check the sources of malloc() and free() for details.

BTW, I've seen some code that checks the endian-ness of the machine
at runtime. This might be a better idea than depending upon MAC
or PC being #defined. The trick is to store an arbitrary value
(like 0x1234) into a short, and looking at the first byte (by
typecasting the address of the variable to a char*).
Just a suggestion.

Cheers,
--
Peter Castine              | Dr. Who quote du jour:
[e-mail]  |     Have you noticed the way people's
===========================| intelligence capabilities decline sharply
 ``Have Mac, will travel'' | the minute they start waving guns around?

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Mon, 6 Jun 1994 17:05:40 GMT
Organization: ISIS International

[e-mail] (Chris Reid) writes:

<snip>

>// RadixSort implemented using malloc() and free()

>mem = FreeMem();    // We've got amount 'mem' bytes in the heap
>RadixSort(someArray, numItems);    // Do the sorting
>waste = mem - FreeMem();    // Is there a memory leak?

>waste is non-zero, a very disturbing fact. But it gets even better,
>because on consecutive calls, waste IS zero. It looks as if
>malloc() remebers what it's done before. By the way, I need to
>use malloc() because the code has to be (sort of) platform independent.

In most implementations of malloc/free, rather than simply calling NewPtr &
DisposePtr directly, they will allocate a larger pool calling NewPtr as
necessary and then manage the space in that pool. In most cases, this pool
storage won't be returned to the mac memory manager, but will remain available
for future malloc() calls. Therefore, FreeMem() will report that storage was
lost.
--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: file://ftp.netcom.com/pub/isis/home.html

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 6 Jun 1994 21:11:22 GMT
Organization: Apple Computer

Chris Reid, [e-mail] writes:
> waste is non-zero, a very disturbing fact. But it gets even better,
> because on consecutive calls, waste IS zero. It looks as if
> malloc() remebers what it's done before. By the way, I need to
> use malloc() because the code has to be (sort of) platform independent.

This is a very Frequently Asked Question. malloc and free as implemented by
the ANSI library (on all know Mac development systems) grab large blocks of
memory via NewPtr, then suballocate those blocks for successive mallocs.
These large blocks don't get returned -- it would be difficult to figure out
when to return them. But the memory in them does get re-used by malloc if you
free it.

Think of it as if malloc and free create a new heap from which to allocate
memory.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Joseph Hall)
Date: Mon, 6 Jun 1994 18:48:45 GMT
Organization: Motorola Inc., Satellite Communications

Seems it was [e-mail] (Chris Reid) who said:
>Hi everybody,
>
>I have written some code that implements Radix Sort (it sorts
>an array of longs in linear time). It seems to work well enough,
>but one thing is really strange: when I replace the NewPtr()
>calls with calls to malloc(), the corresponding free() doesn't seem
>to work. Here's roughly what happens:

It used to be that THINK C's free() just didn't free blocks.  It
was meant to work that way.  I don't recall whether it didn't free
any blocks or whether it only freed blocks larger than a certain size.

MPW's malloc(), on the other hand, was busted around 3.0 or 3.1.
Do some malloc-ing and some free-ing and eventually it would crash.
I don't know whether that was ever fixed, though I reported it.

I suggest that you use NewPtr() on the Mac to obtain memory, then
manage it with a memory allocator of your own.  The Aho/Hopcroft/
Ullman algorithms book has a section on allocators, or you could
just make allocations of the desired size with NewPtr().  You can always
obtain a separate zone to work with, too, which makes it easy to
free a whole bunch of stuff en masse.

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 [e-mail] (home)
(on assignment)    | [phone] (work)  [e-mail]

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Wed, 8 Jun 1994 00:53:17 GMT
Organization: The Information Workshop

It seems to me that one should be able to copy the source code for
malloc() and free() into their project, and then determine how to modify
it to actually free the memory that was originally malloc'd.

This is what I figure I am going to have to do, because I just discovered
that when I made this routine into a code resource (XCMD) which will run
within HyperCard, it used malloc, and I absolutely must return that
memory, and there is no way I could possibly convert the source code to
using NewPtr without opening a Pandora's Box.  It's just too complex.

<sigh>

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Ray Davison) (Ray Davison)
Date: Fri, 10 Jun 1994 22:34:46 GMT
Organization: Simon Fraser University

In article <[e-mail]>, Mark Hanrek <[e-mail]> wrote:

> It seems to me that one should be able to copy the source code for
> malloc() and free() into their project, and then determine how to modify
> it to actually free the memory that was originally malloc'd.
>
> This is what I figure I am going to have to do, because I just discovered
> that when I made this routine into a code resource (XCMD) which will run
> within HyperCard, it used malloc, and I absolutely must return that
> memory, and there is no way I could possibly convert the source code to
> using NewPtr without opening a Pandora's Box.  It's just too complex.

I once needed to use some Unix code and also didn't want it to use malloc
and free. All I did was include the following in the source:

#define free(p) DisposPtr((Ptr)(p))
#define calloc(s,n) ((void *)NewPtrClear(s*n))
#define malloc(s) ((void *)NewPtr(s))

Worked fine for me.

--
Ray Davison
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Sun, 12 Jun 1994 15:28:36 GMT
Organization: PRZ TU-Berlin

[e-mail] (Ray Davison) (Ray Davison) writes:
>
>I once needed to use some Unix code and also didn't want it to use malloc
>and free. All I did was include the following in the source:
>
>#define free(p) DisposPtr((Ptr)(p))
>#define calloc(s,n) ((void *)NewPtrClear(s*n))
                                         ~~~~~
>#define malloc(s) ((void *)NewPtr(s))
>
>Worked fine for me.

Just on principle, it might be a better idea to put parentheses
around s and n in the macro {to wit: NewPtrClear((s)*(n)) }.
It is, admittedly, a little rare to have complicated expressions
as parameters to calloc, but 't can happen.

Picky me ;-}

--
Peter Castine              | Dr. Who quote du jour:
[e-mail]  |     Have you noticed the way people's
===========================| intelligence capabilities decline sharply
 ``Have Mac, will travel'' | the minute they start waving guns around?

---------------------------

>From [e-mail] (Jake V. Bouvrie)
Subject: Closing Down the FINDER
Date: Sun,  5 Jun 94 11:52:50 EST
Organization: (none)

Is it possible to quit the finder from your app, so that there isn't a finder to
go to ?

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: 5 Jun 1994 10:33:24 -0700
Organization: California State University San Marcos

Jake V. Bouvrie ([e-mail]) wrote:
>Is it possible to quit the finder from your app,
>so that there isn't a finder to go to ?

Sure, send it a 'quit' apple event.
Under system 6 it's harder.

Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu


+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Sun, 5 Jun 1994 18:19:43 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Do you mean in code or in practice?

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: 5 Jun 1994 17:03:01 -0700
Organization: Skunkworks

In article <2st294$[e-mail]>,
Marshall Clow <[e-mail]> wrote:
>Jake V. Bouvrie ([e-mail]) wrote:
>>Is it possible to quit the finder from your app,
>>so that there isn't a finder to go to ?
>Sure, send it a 'quit' apple event.

Not so fast; there are issues to consider.  Pasted
below is the discussion from the Finder Q&A tech note
(TB 535).

Grobbins             [e-mail]

Usual disclaimers apply.

______


from Macintosh Technical Note TB 535 - Finder Q&As:

Quitting System 7 Finder
Date Written:  4/17/92
Last reviewed:  6/14/93
I've been thinking of shutting down the System 7 Finder. Is this a cool
thing to do in my application?
___
We normally recommend that you don't quit the System 7 Finder application.
Nevertheless, there may be a few good reasons to shut down the Finder. For
example, the Installer (the only application Apple ships with a good reason
to do so) sometimes needs to shut down the Finder and all other applications
to make sure system resources aren't being used while they're being updated
by the Installer.

If you find yourself in a situation where you need to shut down the Finder,
you should know about a few things:
* Before you shut down the System 7 Finder, use the Process Manager to see
if the File Sharing Extension is running. If so, you should shut it down
before shutting down the Finder. The File Sharing Extension shouldn't be
running without the Finder because the Finder is the only user interface the
File Sharing Extension has. You shouldn't take away the user interface to
file sharing.

 There's another good reason to shut down the File Sharing Extension before
the Finder. The Network Extension (not the Network control panel) handles
all the user interface transactions among the Finder, the File Sharing
Monitor control panel, the Sharing Setup control panel, the Users & Groups
control panel, and the File Sharing Extension (the file server). The Network
Extension opens another file, the Users & Groups Data File, so that it can
manipulate users and groups. When you shut down the Finder (with a
kAEQuitApplication Apple event), the Network Extension and its connection to
the Users & Groups Data File are also closed (almost). Because of a minor
bug in the system, the File Manager thinks that the file is closed and that
the FCB used by that access path is free for reuse; however, the File
Sharing Extension thinks the access path to the Users & Groups Data File
from the Network Extension is still open. When the File Manager attempts to
reuse that FCB to open another file later, the file is opened, but because
the File Sharing Extension thinks that FCB is still in use by the Network
Extension, it won't allow access to the file and it returns opWrErr (-49) to
the Open call. At this point, the file that someone was attempting to open
can't be accessed or closed.

* If the Finder is shut down and then eventually relaunched, there may be
some fragmentation of the MultiFinder heap. This can occur because the
Finder is the first application to be started, so it's always first in the
MultiFinder heap. When you shut it down, that memory becomes available and
other processes might occupy that space. When the Finder is restarted, if it
can't get into its original space in the MultiFinder heap, it will get
loaded somewhere else and probably won't be shut down again.

* In System 7, the Finder is responsible for filling the Apple menu with the
items in the Apple Menu Items folder. When the Finder is gone, so are the
Apple menu items, including things that are important to most users (like
control panels).

* If the user has selected background printing with a LaserWriter or
StyleWriter, nothing will print while the Finder is gone. That's because the
Finder is responsible for monitoring the PrintMonitor Documents folder and
launching the PrintMonitor application when necessary.


+++++++++++++++++++++++++++

>From [e-mail] (Jake V. Bouvrie)
Date: Sun,  5 Jun 94 21:31:29 EST
Organization: (none)

>Do you mean in code or in practice?
Well, i mean in Code, like i call it in my program....

+++++++++++++++++++++++++++

>From [e-mail]
Date: Wed, 08 Jun 1994 14:29:18 EST
Organization: BMUG Boston

[e-mail] (Jake V. Bouvrie) wrote:

>Is it possible to quit the finder from your app, so that there
>isn't a finder to go to ?

Yes.  Assuming you don't mind that it's not a nice thing to do,
you can use Process Manager calls (see IM VI or whatever new
world volume has it) to kill the Finder.  You should also
kill the background process that the File Sharing extension
runs when sharing is turned on - to do otherwise risks
corrupting the Users & Groups file.  This won't get rid of the
Finder forever - it will restart as soon as all other
applications quit.

Dave
-BMUG Boston 617-721-5840, East Coast BBS of The World's Largest Mac User Group

+++++++++++++++++++++++++++

>From [e-mail] (Scott Lindsey)
Date: Wed, 08 Jun 1994 20:14:43 -0800
Organization: Claris Corporation, Vancouver WA

In article <2stp3l$[e-mail]>, [e-mail] (Grobbins) wrote:

> In article <2st294$[e-mail]>,
> Marshall Clow <[e-mail]> wrote:
> >Jake V. Bouvrie ([e-mail]) wrote:
> >>Is it possible to quit the finder from your app,
> >>so that there isn't a finder to go to ?
> >Sure, send it a 'quit' apple event.
>
> Not so fast; there are issues to consider.  Pasted
> below is the discussion from the Finder Q&A tech note
> (TB 535).
>

Not to mention that PowerTalk has certain Finder dependencies.  There's
lots of things that don't work if the Finder isn't running (or even if it
gets relaunched!)  We ran into problems just using Apple's Installer.
After the Finder restarts, PowerTalk gets in a funny state where it's
basically useless.

--
Scott Lindsey <[e-mail], [e-mail]>
Std. disclaimer: my opinions, not Claris', not Apple's.

---------------------------

>From "Andrew C. Plotkin" <[e-mail]>
Subject: Fat-stripping
Date: Thu,  2 Jun 1994 14:52:31 -0400
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

Which is to say, cutting a fat binary down to a 68K executable, thus
saving space. And the parallel operation of cutting a fat binary down to
a PowerMac executable.

Someone must have written a tiny app to do this. Someone? Anyone? I just
downloaded JPEGview 3.3, which is wonderful, but it looks like I can
save half the disk space it takes up. This situation will continue to
aggravate as fat binaries catch on.

(Reassurance: obviously, if I give anyone a copy of a shareware program
which I have fat-stripped, I am obligated to tell them that fact and
point them at an unadulterated version if they want it. Also, some
shareware packages prohibit distributing altered copies at all, and this
would certainly count as alteration. I think a well-behaved fat-stripper
would append "68K" or "PMac" to the executable file name.)

If nobody has written this thing, I guess I will. The fat->68K stripper,
anyhow. Unless it's non-trivial (which I guess is the only reason for it
not being written.) Can one just reduce the data fork of the APPL to
zero length, or is it trickier?

--Z

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Fri, 03 Jun 1994 00:04:49 -0800
Organization: Infinity Systems

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

> Which is to say, cutting a fat binary down to a 68K executable, thus
> saving space. And the parallel operation of cutting a fat binary down to
> a PowerMac executable.
>
> Someone must have written a tiny app to do this. Someone? Anyone? I just
> downloaded JPEGview 3.3, which is wonderful, but it looks like I can
> save half the disk space it takes up. This situation will continue to
> aggravate as fat binaries catch on.
>
> (Reassurance: obviously, if I give anyone a copy of a shareware program
> which I have fat-stripped, I am obligated to tell them that fact and
> point them at an unadulterated version if they want it. Also, some
> shareware packages prohibit distributing altered copies at all, and this
> would certainly count as alteration. I think a well-behaved fat-stripper
> would append "68K" or "PMac" to the executable file name.)
>
> If nobody has written this thing, I guess I will. The fat->68K stripper,
> anyhow. Unless it's non-trivial (which I guess is the only reason for it
> not being written.) Can one just reduce the data fork of the APPL to
> zero length, or is it trickier?

I've written such a thing, mostly, anyway.  This type of program is much
more complicated than it may first appear.

The main reason I haven't released/finished mine is that I'm somewhat
worried about the liability if the stripping process damages someone's
application.  And it might be that the stripping will work fine, but if
they try to run it later on the other type of machine, it might do
something bad (rather than just fail to work).  This could be a problem
that would take months, even years to develop, so the original copy might
have been around for easy restoration.

Also, stripping 68K code is practically impossible to do safely for various
reasons.

_troy gaul
 infinity systems

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Sat, 04 Jun 1994 22:14:44 -0700
Organization: Infinity Systems

In article <[e-mail]>,
[e-mail] (Eric Scouten) wrote:

> You don't really have that much to worry about. If you're writing to strip
> PowerPC code, you only have to read the 'cfrg' resource, find out where the
> PowerPC code is, and get rid of it. In almost all cases, it will be in the
> data fork -- though it is possible to put it in resources (or a *part* of
> the data fork). Such cases are *very* rare, and unsupported by at least two
> of the three major PowerPC development systems.
>
> If you strip the PPC code properly, you can still launch the application on
> a PPC machine; it'll just run in emulation mode instead. (Just be sure you
> also remove the 'cfrg' resource!)

My program actually parses the 'cfrg' resource, and it is aware of the
types of the blocks, etc. (for instance, when the Code Fragment Manager is
implemented on 68K, it won't remove those).

The problem with stripping 68K code is that a PowerPC application might
need some of the code resources if it has only been partially ported, and
this is not described in the 'cfrg' resource or anywhere else.

_troy
//////// //////___Troy [e-mail]__ //
  //    //       Infinity Systems ; Redmond, Washington                //
 //    //  //  "Insert witty quote here."                             //
//    //////________________________________________________________ //

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Mon,  6 Jun 1994 10:41:25 -0400
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

Thanks to everyone who replied. The generic answer seems to be "get
IM-PPC System Software and look up the 'cfrg' resource," which I will do
as soon as my other fifty-seven projects allow me some spare time.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Sun, 12 Jun 94 08:55:52 PST
Organization: Berkeley Macintosh Users Group

[e-mail] (Eric Scouten) writes:

>If you strip the 68K code properly, you can of course launch on a PPC
>machine. If you attempt to launch such an app on a 68K machine, the Finder
>will give you an error box saying something like "The application could not
>be launched because an error of type -192 occurred." (-192 is resource not
>found, probably the 'CODE 1' resource) This is harmless; it just means you
>won't be able to use the app. (Unless they ever come out with PowerPC
>emulation on 68K... snicker snicker!)

Or, you could substitute for the 68k code a tiny 68k program that puts up
an alert saying "This program will not run on your machine because it has
been customized for PowerMac execution only."  Then you don't have to
explain what "an error of type -192" means.

-Ron Hunsinger

---------------------------

>From [e-mail] (Eric Shieh)
Subject: Finder Comments and Finder Info Updating
Date: 9 Jun 1994 21:48:21 GMT
Organization: University of California, Berkeley


Hello all, there are a few minor quirks I'm trying to fix in my program.
First, how do you get the comments off of a floppy disk???IM VI says
it doesn't use the Desktop Manager for volumes < 2 megs, so you cant
use PBDTGetComment...I tried using the Morefiles routine, but it doesn't
seem to like floppies either...

Second problem: Is there any way to have the Finder update a file's label?
On a Powermac, whenever I set the label, then do a GetFInfo, the old label
is still returned, only when I close and re-open the folder does the label
get correctly set.  I tried "touching" the folder (usually used for
updating a file's icons) to no avail. This is annoying cuz my program
can read the label, but if the user changes it, then immediately give it to
my program, it'll read the old label still...

Thanks,
Eric
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Sun, 12 Jun 1994 23:13:14 GMT
Organization: Aladdin Systems, Inc.

In article <2t82n5$[e-mail]>, [e-mail]
(Eric Shieh) wrote:

> Hello all, there are a few minor quirks I'm trying to fix in my program.
> First, how do you get the comments off of a floppy disk???IM VI says
> it doesn't use the Desktop Manager for volumes < 2 megs, so you cant
> use PBDTGetComment...I tried using the Morefiles routine, but it doesn't
> seem to like floppies either...
>
   Correct.  Floppies (volumes < 2 meg) use the old Sys6 style DTDB for
which there were no API calls for accessing the information.  Your only
option, if you MUST support it, is to figure out the format of the old
DTDB files and then read/write them...


> Second problem: Is there any way to have the Finder update a file's label?
>
   Not w/o a bunch of weird trap patches, nope.

   The problem is that the Finder keeps certain things in an internal
"cache" and doesn't go back to disk (or doesn't flush it to disk) that
often.  There is also no (easy/approved/documented) way to get the Finder
to flush the cache, or reload the data.   There is an Apple event in the
new Scriptable Finder that allows you to force an "update" on a file, but
that doesn't help in all cases.


Leonard
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

---------------------------

>From Neil Ticktin <[e-mail]>
Subject: MacTech's ftp site now available!
Date: Thu, 9 Jun 1994 05:09:17 GMT
Organization: MacTech Magazine/Xplain Corp.

To all,

By popular demand (mostly from you folks on comp.sys.mac.programmer),
we've now established our ftp site.  To get to our files, do an anonymous
ftp to ftp.netcom.com and change directories to /pub/xplain -- there
you'll see our latest files.

In this site, we will regularly post the most recent 3 months of source
code to accompany the articles in the magazine.  That way, you can
download the info and play with the code as soon as you get the magazine.
 This brings our Internet support inline with our support on America
Online, CompuServe and AppleLink.

Please let us know if you have any suggestions.

Hope it helps,

Neil Ticktin
MacTech Magazine
- ---------------------------------------------------------------------
           Neil Ticktin, MacTech Magazine (formerly MacTutor)
PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: [phone]
 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  [e-mail] * [e-mail] * [e-mail]
[e-mail] * [e-mail] * [e-mail]
   [e-mail] * [e-mail] * [e-mail]

---------------------------

>From Willie Abrams <[e-mail]>
Subject: QuickDraw GX Display Devices
Date: 6 Jun 1994 19:03:50 GMT
Organization: OU Health Sciences Center

In working with GX, I was wondering -

When the graphics system gets loaded, I assume GX walks the
list of GDevices known to QuickDraw, and creates viewDevices
for them...

Would it be possible to have GX draw to a display that was not
known to QuickDraw? That is, can GX recognize "GX" only display
hardware?

And since GX does allow for the definition and storage of 48 bit
per pixel data, could GX drive a special display board to help
drive us past the 8 bit grayscale ceiling. Maybe 16 bit grayscale
boards? :-)

This does have an application, really.

Many people in the medical imaging industry and some of our
customers (radiologists, etc.) believe that even though we have
been taught that the human eye can detect no more that 256 shades
of any given tone, that the ability to see 12 bits to 16 bits of
data is worthwhile and can make a difference on diagnosis.


Willie Abrams
Telemedicine Software Guy  Internet:  [e-mail]
OU Health Sciences Center  AppleLink: Willie

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 8 Jun 94 16:39:22 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <2svrum$[e-mail]>, Willie Abrams <[e-mail]> writes:
>
> When the graphics system gets loaded, I assume GX walks the
> list of GDevices known to QuickDraw, and creates viewDevices
> for them...
>
> Would it be possible to have GX draw to a display that was not
> known to QuickDraw? That is, can GX recognize "GX" only display
> hardware?

GX can draw to offscreen ViewDevices, just like QuickDraw supports offscreen
GWorlds. They're easy to set up. You can even set up offscreen ViewGroups
(like the set of all screen devices is a ViewGroup), so you can draw a single
shape to multiple offscreen ViewDevices with a single GXDrawShape call.

> And since GX does allow for the definition and storage of 48 bit
> per pixel data, could GX drive a special display board to help
> drive us past the 8 bit grayscale ceiling. Maybe 16 bit grayscale
> boards? :-)

Unfortunately, last I checked in the (beta) documentation, GX cannot draw
_to_ a destination that has more than 8 bits per pixel component. I think it
can only read _from_ such a bitmap.

In short, you can certainly create and manipulate such a structure yourself,
no problem. And you can even get GX to display and print it (to within the
limits of your output hardware) once you've done. But GX will only be of
limited help with the manipulations.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From Cary Clark <[e-mail]>
Date: Wed, 8 Jun 1994 04:42:51 GMT
Organization: Apple Computer, Inc.

In article <2svrum$[e-mail]> Willie Abrams,
[e-mail] writes:
>Would it be possible to have GX draw to a display that was not
>known to QuickDraw? That is, can GX recognize "GX" only display
>hardware?

Yes. An application can create a device in with the gxScreenViewDevices
viewGroup (1), and then it will be treated like all other physical
devices. If nil is passed for the mapping to GXSetViewDeviceMapping, the
device will be located adjacent to but not overlapping the other physical
devices.

>And since GX does allow for the definition and storage of 48 bit
>per pixel data, could GX drive a special display board to help
>drive us past the 8 bit grayscale ceiling. Maybe 16 bit grayscale
>boards? :-)

Sorry, but GX does not allow for pixel sizes greater than 32 bits. Nor
does it provide for 16 bits/pixel grayscale. But both of these are fine
enhancement requests for version 2.0.

Cary Clark
Apple Computer, Inc.

---------------------------

>From [e-mail] (Chris Kaltwasser)
Subject: SEMI-SUMMARY: Reading JPEGs (with code)
Date: 8 Jun 1994 03:45:29 GMT
Organization: Oregon State University, Corvallis

Hello all,
    A while ago, I asked for a little help/advice on decompressing
JPEGs from JFIF files using QuickTime, and I'm very pleased to be able to
report success.  For the benefit of the Mac programming community, here is
the product of my efforts:

    This routine reads a JPEG file into an offscreen GWorld.  It would
not be too difficult to modify it to use an onscreen port instead.  It
assumes you've already checked for QuickTime and so forth.  Permission is
given to use this code for non-commercial purposes.  Use at your own risk.

- ------------------Cut Here--------------------

//______________________________________________________________________
//
//    Code for reading and writing JFIF files for SSConverter 1.4.1
//
//    Copyright (c)1994 by Chris Kaltwasser.  All rights reserved.
//
//______________________________________________________________________



#include <ImageCompression.h>
#include <FixMath.h>



#define JFIF_ID_MARKER        0xE0
#define JFIF_INFO_MARKER    0xC0



OSErr ReadJPEGFile(FSSpec *spec, GWorldPtr *gw)
{
    Rect srcRect;
    GDHandle gdh;
    PixMapHandle pix;
    ImageDescriptionHandle descH;
    CGrafPtr port;
    Byte *data = NULL, *s, id[5] = "JFIF";
    long length, i;
    short j, refnum, err, width, height;

    if (*gw)
        DisposeGWorld(*gw);
    *gw = NULL;

    err = FSpOpenDF(spec, fsRdPerm, &refnum);
    if (!err)
    {
        err = GetEOF(refnum, &length);
        if (!err && length < 170L) err = kReadFailErr;
        if (!err)
        {
            data = (Byte*)NewPtr(length);
            if (!data) err = memFullErr;
        }
        if (!err)
            err = FSRead(refnum, &length, data);
        FSClose(refnum);
    }

    if (!err)
    {
        /* make sure data is JFIF data stream */
        for (i = 0; i < length; ++i)
            if (data[i] == 0xFF && data[i+1] == JFIF_ID_MARKER)
            {
                for (s = &data[i+4], j = 0; j < 5; ++s, ++j)
                    if (*s != id[j])
                    {
                        err = kBadJFIFErr;
                        j = 5;
                    }
                i = length;
            }
        if (err) goto abortJPEG;

        /* read JPEG height and width from JFIF stream */
        err = kBadJFIFErr;
        for (i = 0; i < length; ++i)
            if (data[i] == 0xFF && data[i+1] == JFIF_INFO_MARKER)
            {
                height = data[i+5]*256 + data[i+6];
                width = data[i+7]*256 + data[i+8];
                err = noErr;
                i = length;
            }

        if (!err)
        {
            srcRect.top = 0;
            srcRect.left = 0;
            srcRect.bottom = height;
            srcRect.right = width;

            err = NewGWorld(gw, 24, &srcRect, NULL, NULL, 0);

            GetGWorld(&port, &gdh);
            SetGWorld(*gw, NULL);
            ClipRect(&srcRect);
            ForeColor(blackColor);
            BackColor(whiteColor);

            descH = (ImageDescriptionHandle)NewHandle(sizeof(ImageDescription));
            HLock((Handle)descH);
            (**descH).idSize = sizeof(ImageDescription);
            (**descH).cType = 'jpeg';
            (**descH).resvd1 = 0L;
            (**descH).resvd2 = 0;
            (**descH).dataRefIndex = 0;
            (**descH).version = 1;
            (**descH).revisionLevel = 1;
            (**descH).vendor = 'appl';
            (**descH).temporalQuality = 0;
            (**descH).spatialQuality = 0;
            (**descH).width = width;
            (**descH).height = height;
            (**descH).vRes = (**descH).hRes = Long2Fix(72L);
            (**descH).dataSize = length;
            (**descH).frameCount = 1;
            BlockMove("\pPhoto - JPEG", (**descH).name, 32L);
            (**descH).depth = 24;
            (**descH).clutID = -1;
            HUnlock((Handle)descH);

            pix = GetGWorldPixMap(*gw);

            if (LockPixels(pix))
            {
                err = DecompressImage((Ptr)data, descH, pix, &srcRect, &srcRect,
                                    srcCopy, NULL);
                UnlockPixels(pix);
            }
            else
                err = memFullErr;

            SetGWorld(port, gdh);                    /* restore port and device */

            DisposeHandle((Handle)descH);
        }
    }

abortJPEG:
    if (data) DisposePtr((Ptr)data);

    return err;
}

---------------------------

>From [e-mail] (Joakim Grebeno)
Subject: VBL interrupt & Stack Sniffer
Date: 10 Jun 1994 07:53:37 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden

I can't, over my dead body, find the information describing how to
enable/disable the stack sniffer! It is supposed to be done by toggling
a number of system globals but I can't find the info neither in IM 1-6
nor in the technotes!

I have the same problem to find which slot in the exception table the
VBL interrupt occupies!

Any experiences?

Thanks in advance!
Joakim

--
Joakim Grebenoe


+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: 10 Jun 1994 12:24:44 GMT
Organization: Program of Computer Graphics -- Cornell University

I did this once, there is only one low mem global (try 0x0110?) and it used to
have the name StackLowPt, but I can't find it in the headers anymore. anyway,
just write a zero to that location to disable the sniffer.

BTW, it seems that the thread manager extension from apple already disables
the sniffer on a global basis. can anybody substantiate this? Protected mem
would be a better scheme...
--
_______________________________________________________________________________

   Bretton Wade ([e-mail])

   Program of Computer Graphics
   580 Engineering and Theory Center
   Cornell University
   Ithaca, NY 14853
   Voice: [phone]
   Fax:   [phone]
_______________________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Fri, 10 Jun 1994 15:51:26 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <2t9661$[e-mail]>,
Joakim Grebeno <[e-mail]> wrote:
>I can't, over my dead body, find the information describing how to
>enable/disable the stack sniffer! It is supposed to be done by toggling
>a number of system globals but I can't find the info neither in IM 1-6
>nor in the technotes!

Set the low-memory global StkLowPt to 0.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Fri, 10 Jun 1994 15:52:52 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <2t9m2c$[e-mail]>,
Bretton Wade <[e-mail]> wrote:
>BTW, it seems that the thread manager extension from apple already disables
>the sniffer on a global basis. can anybody substantiate this? Protected mem
>would be a better scheme...

The last version of the TM (pre-2.0) that I checked just set StkLowPt to zero.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Brad Pickering)
Date: 10 Jun 1994 17:59:29 GMT
Organization: Jet Propulsion Laboratory, Pasadena, CA

In article <2t9661$[e-mail]> [e-mail] (Joakim Grebeno) writes:

   Path: elroy.jpl.nasa.gov!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!EU.net!sunic!sics.se!eua.ericsson.se!eua.ericsson.se!euajgo
   From: [e-mail] (Joakim Grebeno)
   Newsgroups: comp.sys.mac.programmer
   Date: 10 Jun 1994 07:53:37 GMT
   Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
   Lines: 16
   NNTP-Posting-Host: euas66c13.eua.ericsson.se
   Keywords: VBL, Stack Sniffer

   I can't, over my dead body, find the information describing how to
   enable/disable the stack sniffer! It is supposed to be done by toggling
   a number of system globals but I can't find the info neither in IM 1-6
   nor in the technotes!

Set the low memory global called 'StkLowPt' to 0.
#include <SysEqu.h>

*(long *)StkLowPt = 0;

   I have the same problem to find which slot in the exception table the
   VBL interrupt occupies!

I think this depends on which mac you have. On the original macs it
is handled by the autoint1 vector (0x64), which calls some code that
dispatches through the second entry of the level 1 dispatch table (Lvl1DT + 0x04).
Some of this is documented in IM II pg 197.


Brad Pickering

+++++++++++++++++++++++++++

>From [e-mail] (Verret Chris)
Date: 11 Jun 1994 06:56:00 GMT
Organization: Brussels Free Universities (VUB/ULB), Belgium

Joakim Grebeno ([e-mail]) wrote:
: I can't, over my dead body, find the information describing how to
: enable/disable the stack sniffer! It is supposed to be done by toggling
: a number of system globals but I can't find the info neither in IM 1-6
: nor in the technotes!

The following did the trick for me:



Ptr      stkLowPt : 0x110;
Ptr      savedStkLowPt;



savedStkLowPt = stkLowPt;
stkLowPt = NULL;



stkLowPt = savedStkLowPt;

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 12 Jun 1994 15:44:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2t9661$[e-mail]>,
[e-mail] (Joakim Grebeno) writes:

>I can't, over my dead body, find the information describing how to
>enable/disable the stack sniffer!

I put a code snippet on the Developer CD called "Switch Stack" that
shows how to let interrupt code run on a private stack.  It also
disables and re-enables the stack sniffer correctly.

- Jim Luther


---------------------------

>From [e-mail]
Subject: Writing dcmd with Think C (Q)
Date: 8 Jun 94 15:04:44 MET
Organization: University of Neuchatel

 Hi !

 Is it possible to write a dcmd with Think C ? If I include the .0 librairies
 in my project, I get link errors (like DATA_INIT undefined, or something
 like that).

 Is there a Think C port of these librairies available somewhere ?

 Thanks for your help

 Patrick

+++++++++++++++++++++++++++

>From [e-mail] (Eddy J. Gurney)
Date: Wed, 8 Jun 1994 17:30:28 GMT
Organization: Hewlett-Packard VCD

[e-mail] wrote:
> Is it possible to write a dcmd with Think C ? If I include the .0 librairies
> in my project, I get link errors (like DATA_INIT undefined, or something
> like that).

> Is there a Think C port of these librairies available somewhere ?

Even if you do get your 'dcmd' to build under Think, you'll STILL need
MPW to run the "BuildDCMD" Tool which Apple kindly supplies only as an
MPW tool, without any source.

I was about to try the same thing as you when I realized this "gotcha".

However, if someone has come up with a method for building dcmd's under
Think, I would love to hear about it.

--
Eddy J. Gurney N8FPW   Hewlett-Packard Company, Vancouver (USA!) Division
[e-mail]                       #include <standard-disclaimer.h>
"Failures are divided into two classes-- those who thought and never did,
      and those who did and never thought."     John Charles Salak

+++++++++++++++++++++++++++

>From [e-mail] (Elizabeth Scharf)
Date: 9 Jun 1994 04:21:53 GMT
Organization: University of Washington, Seattle

I managed to get TC 5 to build dcmds by using custom headers.  The main
file looked like this:

void    CommandEntry    (void);
void    main            (void);

void main (void)
{
    asm {
        @valid_A4:
            dc.w    2
            dc.w    0
            lea        @valid_A4,a0
            bra        CommandEntry
        } /* asm */

}

(remember, for a custom header, put NOTHING else in this file!)

The main dcmd entrypoint looked like this:

#include <SetUpA4.h>
#include "dcmd.h"

pascal void CommandEntry (

    dcmdBlock    *paramPtr)

    { /* begin CommandEntry */

        RememberA0();
        SetUpA4();

        switch (paramPtr->request) {
...

            } /* switch */

        RestoreA4();

    } /* end CommandEntry */

(and you even get globals!)

I think I used oconv on the dcmdGlue.Lib, but it was a while ago...

Hope this helps.

rmgw

This is not my account:  Please address replies to [e-mail]

Disclaimer:  All views expressed are entirely my own and do not reflect
the opinions of Elizabeth Scharf or the University of Washington.

- ---------------------------------------------------------------------------
Richard Wesley             | A Capitalist is someone who   | "Intel Inside"
[e-mail]           | knows the price of everything | is a warning
[e-mail]  | and the value of nothing.     | label...
- ---------------------------------------------------------------------------


---------------------------

End of C.S.M.P. Digest
**********************